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Abstract 


There  is  a  middle  ground  between  parametric  and  ad-hoc  polymorphism  in  which  a  com¬ 
putation  can  depend  upon  a  type  parameter  but  is  restricted  to  being  defined  at  aU  types 
in  an  inductive  fashion.  We  call  such  polymorphism  non-parametric.  We  show  how  non- 
parametric  polymorphism  can  be  used  to  implement  a  variety  of  useful  language  mech¬ 
anisms  including  overloading,  unboxed  data  representations  in  the  presence  of  ML-style 
polymorphism,  and  canonical  representations  of  equivalent  types.  We  show  that,  by  using 
a  second-order,  explicitly  typed  language  extended  with  non-parametric  operations,  these 
mechanisms  can  be  implemented  without  having  to  tag  data  with  type  information  at  run¬ 
time.  Furthermore,  this  approach  retains  a  “phase  distinction”  and  permits  static  type 
checking  and  separate  compilation.  Our  aim  is  to  provide  a  unifying  language,  translation, 
and  proof  framework  in  which  a  variety  of  non-parametric  mechanisms  can  be  expressed 
and  verified. 


1  Introduction 


Polymorphism  is  the  parameterization  of  an  expression  by  a  type.  Traditionally,  polymor¬ 
phism  is  divided  into  two  classes,  parametric  and  ad-hoc[13].  Roughly  speaking,  parametric 
polymorphism  is  uniform  in  that  the  computation  cannot  depend  upon  the  type  that  in¬ 
stantiates  the  parameter,  while  ad-hoc  polymorphism  can  depend  upon  the  type  and  need 
not  be  defined  at  all  types.  In  particular,  ad-hoc  operations  such  as  “-h”  may  only  be 
defined  to  work  on  a  small  number  of  types. 

There  is  a  middle  ground  between  parametric  and  ad-hoc  polymorphism  in  which  the  com¬ 
putation  can  depend  upon  the  type  parameter  but  is  restricted  to  being  defined  at  all  types 
in  an  inductive  fashion.  We  call  such  polymorphism  non-parametric.  In  this  paper,  we  show 
how  non-parametric  polymorphism  can  be  used  to  implement  a  variety  of  useful  language 
mechanisms  including  overloading,  unboxed  data  representations  in  the  presence  of  ML- 
style  polymorphism,  and  canonical  representations  of  equivalent  types.  We  show  that,  by 
using  a  second-order,  explicitly  typed  language  extended  with  non-parametric  operations, 
these  mechanisms  can  be  implemented  without  having  to  tag  data  with  type  information  at 
runtime.  Finally,  we  remark  that  our  approach  retains  a  “phase  distinction”  and  permits 
static  type  checking  and  separate  compilation. 

Using  a  second-order  explicitly  polymorphic  language  to  implement  non-parametric  lan¬ 
guage  features  is  not  a  new  idea.  Morrison  et  al.  describe  an  implementation  of  NapierSS 
that  uses  type  information  at  run  time  to  determine  properties  such  as  layout  of  an  object[ll]. 
Tolmach  has  shown  how  to  do  “almost  tag-free”  garbage  collection  for  parametric  languages 
such  as  SML  by  encoding  them  into  a  second-order  language[14].  Ohori  shows  how  poly¬ 
morphic  field  selection  can  be  implemented  by  first  encoding  the  source  into  a  second-order 
language  and  then  translating  types  to  index  structures[12].  However,  all  of  these  efforts 
were  directed  toward  a  single  language  mechanism  (e.g.  garbage  collection)  and  only  Ohori 
presents  a  formal  account.  Our  aim  is  to  provide  a  unifying  language,  translation,  and  proof 
framework  in  which  a  variety  of  non-parametric  mechanisms  can  be  expressed  and  verified. 

This  paper  proceeds  as  follows:  In  Section  2,  we  present  a  simple  source  language,  based  on 
Mini-ML[4];  an  explicitly  typed  target  language  ,  based  on  XML[10];  and  a  translation 
technique  that  compiles  Mini-ML  into  X^^ .  In  Section  3,  we  extend  X^^  to  provide  a 
non-parametric  operator,  typerec  and  in  Sections  4,  5,  and  6,  we  show  how  the  translation 
technique  can  be  used  to  provide  non-parametric  language  extensions  for  Mini-ML. 


2  Compiling  ML  to 

2.1  The  Mini-ML  Source  Language 

Below,  we  give  the  abstract  syntax  for  the  types,  type  schemes,  expressions,  and  values  of 
Mini-ML. 

T  e  type  ::= 

a  G  scheme  ::= 

e  G  term 

V  G  value  ::= 


t  1  unit  I  ri  X  r2  1  Ti^T2 
Vti ,  . . . , tn •T 

X  10  l(ei,e2)  liTie  |7r2e  | fixa;i(a;2).e  leie2  [let  x  =  vine 

®  i()  lfixa;i(x2).e 
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In  the  interests  of  simplicity,  Mini-ML  types  include  only  type  variables  (t),  unit,  binary 
products,  and  functions.  Type  schemes  are  prenex  quantified  types.  Expressions  include 
identifiers,  unit,  tuples,  projections,  applications,  let  expressions,  and  fix  expressions  of  the 
form  fixxi(a:2).e.  We  will  use  Xx.e  as  an  abbreviation  for  fixa;'(a:).e  when  x'  is  not  free  in 
e.  Note  that  we  restrict  let-bound  expressions  to  be  values  for  reasons  detailed  in  Section 
2.3. 

A  standard  call-by-value  operational  semantics  in  the  style  of  Felleisen  et  al.[5]  (see  also 
Wright  and  Felleisen[16])  can  be  given  to  Mini-ML  by  defining  evaluation  contexts  (expres¬ 
sions  with  “holes”)  and  one-step  reduction  rules: 

E  e  eval  context  ::=  11  \{E,e)  \  {v,E)  It:,  E  \  E  e \v  E 

(tt)  ELwi  {vi,V2)1  I — !•  Elvil  (f  =  l,2) 

(fixi,/?)  FC(fixa;i(a;2).e)u]  i — F  [[u/a;2][fixa;i(a:2).e/a;i]e] 

(let„/3)  F[let  x  =  v\ne]  i — F[[u/a;]e] 

In  Section  2.3,  we  define  an  equivalent  dynamic  semantics  via  translation  to  another  lan¬ 
guage. 

Figure  1  gives  a  static  semantics  for  Mini-ML  by  defining  two  judgements: 

A  h  r  type  L  e  :  r 

where  F  is  a  type  environment  mapping  identifiers  to  type  schemes  and  A  is  a  set  of 
type  variables.  The  first  judgement  establishes  the  validity  of  a  type  in  the  scope  of  some 
bound  type  variables  by  requiring  all  free  type  variables  to  be  in  A.  The  second  judgement 
ascribes  a  type  to  an  expression.  We  say  that  the  closed  expression  e  has  type  r  if  and  only 
if  0  1-0  e  :  r  is  derivable  from  the  set  of  inference  rules.  The  static  semantics  is  essentially 
the  type  system  for  the  core  of  SML  in  that  polymorphic  types  are  introduced  by  the  let 
expression[9].  Unlike  SML,  we  restrict  the  bound  expression  that  is  assigned  a  generalized 
type  scheme  to  be  a  value. 

We  state  the  following  theorem  without  proof: 

Theorem  1  (Mini-ML  Type  Preservation)  Iffljhii^e-.T  and  e  \ — *•*  v,  then  0  l-0  u  :  r. 

See  Wright  and  Felleisen[16]  for  an  example  of  how  to  prove  this  theorem. 

2.2  The  A^^Base  Target  Language 

In  this  section,  we  introduce  a  base  target  language,  ,  similar  to  XML[10].  A^^is  a 
stratified  second-order  A-calculus  in  which  the  polymorphic  types  live  in  a  “higher  universe” 
than  monotypes.  Conceptually,  the  universe  of  monotypes  is  generated  inductively,  so  we 
are  able  to  give  elimination  forms  corresponding  to  structural  induction  on  monotypes.  As 
we  show  in  Sections  4,  5,  and  6,  these  induction  forms  allow  us  to  implement  a  wide  variety 
of  interesting  and  useful  language  features  in  A^^  . 

The  four  basic  syntactic  classes  of  A^^^ ,  kinds  (k),  type  constructors  (u),  types  (cr),  and 
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FTV{t)  c  a 

r  type 


r(a:)  = 

A  h  ri  type  •  •  •  A  h  type 

r  f-A  a;  :  [ri/ii, . . . , 


r  u  :  -r' 

T,X  .  .  ,tn-T'  \-A  e  ■  T 

r  l-A  let  x  =  v\r\e  :  T 


(ti  i  A) 


r  l-A  0  :  unit 


r  l-A  ei  :  ri  T  I-a  £2  :  7-2 
r  l-A  (61,62)  :  n  X  r2 


r  l-A  TTj-  e  :  Ti 


r,a:i  V.(ri  -»  r2),a;2  !-»  V.n  I-a  6  :  r2 

r  h-A  fixa;i(a;2).e  :  ri  — >  r2 


{xi,x2  i  r) 


r  l-A  61  :  Ti  ^  r2  r  l-A  62  :  n 
r  Ha  61  62  :  T2 


Figure  1:  Static  Semantics  for  Mini-ML 
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terms  (e),  along  with  values  (v)  that  are  a  sub-class  of  terms,  are  given  below: 

/c  G  kind  12  j  /ci  — >  k2  \  k\  x  k2 

u  G  constr  ::=  t  |  unit  | -4  |  x  |  (ui ,  U2)  |  Tr'i  u  1 7f2  w  | ^  ^  '“2 

O'  G  type  ::=  T{t)  |  oi  x  0-2  |  o-j  0-2  |  Vt  :  k.a 

e  G  term  ::=  2;  |  ()  |  (61,62)  |  tti  e  1 7r2  e  |  A  t  :  A:  .e  |  e[u]  |  fix  xi(a;2  :  o-).e  |  ei  62 

V  G  value  ::=  a;  |  ()  |  (ui,U2)  |  At  :  A’ .6  |  fixa;i(a-2  :  o').6 

The  kinds  include  12,  the  collection  of  all  monotypes,  and  are  closed  under  products  and 
function  spaces.  We  use  r,  a  subset  of  constructors,  to  range  over  monotypes: 

T  G  monotype  unit  |  x(ri,  r2)  | -^(ri, r2) 

The  constructors  include  monotypes  such  as  unit  and  type  constructors  such  as  The 
types  of  ,  whose  elements  are  terms,  include  binary  products,  function  spaces,  and  poly¬ 
morphic  types.  In  addition,  types  include  explicitly  “injected”  monotypes  (T(r)).  Finally, 
terms  correspond  to  the  basic  expression  forms  of  Mini-ML  but  are  written  in  an  explicitly 
typed  syntax.  As  in  Mini-ML,  we  use  A  a:  :  a.e  as  an  abbreviation  for  fixa:'(a;  :  a).e  where 
x'  is  not  free  in  e.  There  is  no  need  for  a  let-construct  since  this  is  definable  using  the 
A-abbreviation  together  with  type  abstraction,  but  we  continue  to  use  let  as  a  syntactic 
convenience. 

The  dynamic  semantics  for  A^^^is  defined  by  defining  evaluation  contexts  and  one-step 
reduction  rules: 

E  G  eval  context  ::=  LI  \  {E,e)  \  {v,E)  {ni  E  \  E[u]  \  E  e  \  v  E 

(tt)  EL-Xi  {vi,V2)^  I — ^  ELvil  (f=l,2) 

(A/?)  EL{Kt  :  k  .e)[u\\  ^  EL[ult]e] 

(fixy/3)  £[(fixa;i(a'2  :  (7).6)  u]  1 — >  i^[[u/a:2][fixa-i(a;2  :  aj.c/a'ije] 

Note  in  particular  that  type  abstractions  are  considered  values  and  type  application  has  an 
operational  reduction. 

The  static  semantics  for  A^^^  is  broken  into  a  set  of  formation  judgements  and  equivalence 
judgements.  Full  details  are  given  in  Appendix  A.  Throughout,  we  use  F  to  denote  a  type 
assignment  mapping  identifiers  (a:)  to  types  (a)  and  we  use  A  to  denote  a  context  mapping 
type  variables  (t)  to  kinds  (A). 

The  formation  judgements  include  constructor  formation  (A  h  u  :  A),  type  formation  (A  F 
a  type),  and  term  formation  (F  Fa  e  :  a).  The  constructor  formation  rules  are  the  typing 
rules  for  the  simply  typed  A-calculus  with  products.  Though  A^^^  types  are  similar  to  Mini- 
ML  type  schemes,  quantification  in  A^^is  not  restricted  to  be  prenex  and  types  are  required 
to  be  closed  with  respect  to  quantification  over  all  kinds  (not  just  the  kind  of  monotypes) 
and  function  spaces. 

Term  formation  is  given  by  a  standard  set  of  typing  rules  for  a  second-order  calculus,  with 
the  exception  of  a  type  equivalence  rule: 

F  Fa  e  :  (Tj  A  F  cti  =  0-2  type 
F  Fa  e  :  (72 
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This  rule  is  needed  to  reason  about  explicitly  injected  monotypes  obtained  from  constructors 
(i.e.  T{u)).  Equivalence  for  constructors  is  defined  using  /3 77- conversion.  Hereafter,  we  shall 
elide  the  differences  between  constructors  and  their  corresponding  explicitly  injected  types. 

We  state  the  following  theorem  without  proof: 

Theorem  2  Type-Preservation):  if  0  1-0  e  :  a  and  e  1 — v,  then  0  l-0  u  :  <7. 

A  key  property  of  X^^  is  that  it  maintains  a  phase  distinction.  That  is,  it  is  not  necessary  to 
reason  about  term  equality  in  order  to  show  constructor  equality.  Furthermore,  since  A  is 
explicitly  typed,  type-checking  can  be  reduced  to  checking  constructor  equivalence.  Finally, 
since  types  are  essentially  a  simply-typed  lambda  calculus  extended  with  products 
and  a  single,  inductively  generated  base  kind  (O),  constructor  equivalence  is  decidable  and 
consequently,  so  is  type  checking  of  X^^  [8]. 

2.3  Type-Directed  Translation 

In  this  section,  we  present  a  methodology  for  compiling  Mini-ML-like  languages  to  X^^  - 
like  languages.  Our  approach,  similar  to  the  one  used  by  Leroy[7],  is  to  use  a  type-directed 
translation  where  we  first  present  a  translation  from  Mini-ML  types  to  X^^  constructors 
and  then  use  a  term’s  typing  derivation  to  generate  its  translation  into  the  appropriate 
term.  Here,  we  give  an  example  translation  (the  “standard”  translation)  that  simply 
demonstrates  the  technique.  In  subsequent  sections,  we  extend  X^^  and  use  different,  but 
similar  translations  to  handle  difficult  implementation  issues  that  we  gloss  over  here. 

The  standard  translation  on  types  and  schemes  is  defined  by  |r|s  and  Icrls  respectively: 

t 

unit 

x(|ri|s,|r2|s) 

-^(|ri|s,k2|5) 

|Vti, . . . ,  tn-'r\s  —  Vti  :  fl, . . . ,  tn  :  fi.|T|5 

The  standard  translation  on  terms  is  defined  by  the  judgement  T  \-a  e  :  t  =>s  \e\  where 
r  and  A  are  a  Mini-ML  type  assignment  and  list  of  type  variables  respectively,  e  is  a 
Mini-ML  term,  r  is  a  Mini-ML  type,  and  |e|  is  the  resulting  A^^term.  Conceptually,  we 
take  the  derivation  of  F  La  c  :  t  and  nse  that  to  build  a  corresponding  derivation  of  the 
translation  |e|.  The  judgement  is  defined  formally  in  Appendix  B.  Here,  we  give  the  two 
most  interesting  rules  that  translate  identifiers  and  let-expressions: 

r(2:)  =  Vti , .  .  .  ,  tn 

A  I-  ri  type  •  •  •  A  L  type 
r  La  a;  :  [n/h, . . .  ,r„/t„]r  =»s  a:[lri|s]  •  •  •  [knls] 


\t\s  = 
lunit|5  = 
In  X  r2|5  = 

17-1^7215  = 


r  La,<i,...,7„  v:t'=^s  bl 

_ r,x  Vti,...,tn.T'  La  e  :  r  =»5  |e| _ 

r  La  let  x  =  vine  :  T  =>s 

(Xx  :Vti  :  Q,..., in  ■  fl-lT'|s-|e|)(Ati  :  fl, . . . , tn  :  -l^l)  (li  ^ 
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The  first  rule  makes  type  application  explicit  while  the  second  rule  makes  type  abstraction 
explicit.  Note  that  the  type  translation  used  in  the  first  rule  can  produce  constructors  with 
free  constructor  variables.  However,  due  to  the  requirement  that  A  h  r,-  type,  we  can  show 
that  the  translation  has  bound  these  type  variables  in  an  outer  context  using  the  second 
rule. 

Given  the  syntax-directed  nature  of  the  translation  rules,  it  is  apparent  that  once  a  deriva¬ 
tion  of  r  l-A  e  :  r  is  fixed,  then  there  exists  a  unique  |e|  such  that  F  e  :  r  =?>s  lej.  We 
state  the  following  theorem  without  proof,  using  |r|5  to  denote  the  type  environment  that 
assigns  the  type  |r(a:)|5  to  x  and  |A|  to  denote  the  context  that  assigns  the  kind  9,  to 
each  variable  in  A. 

Theorem  3  (Standard  Translation  Type  Preservation):  IfT  Fa  e  :  r  \e\,  then  |r|5  hiAi 

H:M5. 

We  state  the  following  theorem  without  proof,  where  we  use  6  to  denote  an  “observable 
type”  (i.e.  unit  or  products  of  observable  types)^: 

Theorem  4  (Standard  Translation  Correctness):  // 0  hg  e  :  0  =^5  \e\  and  e  \ — >*  v,  then 
there  exists  a  |v|  such  that  0  1-0  u  :  0  =>5  |u|  and  \e\  1 — |t;|. 

This  theorem  can  be  proved  using  Theorem  3  and  an  erasure  argument,  similar  to  the  one 
described  by  Harper  and  Lillibridge[6]. 

Note  that  the  translation  is  not  valid  for  Standard  ML  programs  since  SML  allows  non¬ 
value  expressions  bound  by  a  let  to  be  assigned  a  generalized  type,  unlike  our  definition 
of  Mini-ML  (see  Section  2.1).  For  instance,  SML  would  assign  a  generalized  type  to  the 
diverging  expression  bound  in  the  following  let-expression: 

let  a:  =  (fix2/(z).2/2:)()in() 

Since  our  translation  scheme  makes  type  abstraction  explicit,  our  translation  would  yield 
the  expression 

(A(a;  :  Vt  :  fl.t).{))[At  :  9  .(fix y(z  :  unit).y 2)()) 

that  (incorrectly)  terminates.  Thus,  we  limit  generalization  in  Mini-ML  to  syntactically 
apparent  values.  Fortunately,  Wright  has  shown  that  this  value  restriction  is  reasonable  in 
practice  for  languages  such  as  SML[17].  Furthermore,  this  restriction  solves  the  well  known 
problems  of  generalization  in  the  presence  of  other  computational  effects  including  mutable 
objects  and  first  class  continuations. 

Given  the  value  restriction,  it  is  possible  to  eliminate  all  polymorphism  at  compile  time  by 
duplicating  and/or  inlining  let-bound  values.  We  do  not  consider  this  approach  reasonable 
since  it  prevents  effective  separate  compilation  of  polymorphic  definitions. 


3  Non-Parametric 

In  this  section,  we  discuss  non-parametric  extensions  to  A^^^that  allow  us  to  “match  and 
recur”  over  the  constructors  of  a  monotype  to  determine  a  computation.  Recall  from  Section 

'The  theorem  still  holds  if  we  extend  with  another  primitive  “observable”  type  such  as  int  with 
more  than  one  value. 
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2.2  that  the  type  system  of  A^^is  stratified  so  that  polymorphic  types  live  in  a  higher 
universe  than  monotypes  and  monotypes  are  conceptually  generated  inductively.  Thus, 
it  is  possible  to  define  well-founded  induction  elimination  forms  for  monotypes.  In 
this  section,  we  show  how  one  general  elimination  form  called  typerec  may  be  added  to 
\ML  without  destroying  the  phase  distinction.  In  Sections  4  and  5,  we  show  how  typerec  may 
be  used  to  implement  overloading  and  canonical  representations  for  Mini-ML.  In  Section  6, 
we  use  other  non-parametric  extensions  to  to  support  unboxed  representations. 

To  add  typerec  to  A^^ ,  we  augment  the  syntactic  classes  as  follows; 

u  G  constr  ::=  ...  |TypeRec(r;  Uy;  u^) 

e  G  term  ...  |typerec(r;  Cy;  e^;  e_,.) 

We  add  typerec  to  the  terms  and  the  corresponding  TypeRec  to  the  constructors.  Intuitively, 
typerec  corresponds  to  a  combination  of  a  “type-case”  operator  with  a  “type-recursion” 
operator,  so  that  computations  may  depend  upon  a  single  type. 

Before  giving  the  changes  to  the  dynamic  semantics  to  support  typerec,  we  note  that  com¬ 
putations  involving  typerec  will  depend  upon  the  type  constructor  used,  so  we  need  to 
evaluate  constructors  to  a  canonical  form.  Since  types  in  are  essentially  a  simply 
typed  A-calculus  extended  with  products,  TypeRec,  and  a  single  base  kind  of  monotypes 
but  no  fix-point  construct,  we  note  that  such  normal  forms  exist  and  can  be  found  using, 
for  instance,  caU-by-name,  call-by-need,  or  caU-by-value  evaluation  strategies. 

The  one-step  evaluation  relation  for  terms  is  augmented  so  that  typerec  evaluates  its  type 
constructor  argument.  It  then  uses  the  root  constructor  of  the  canonical  form  to  select  the 
appropriate  sub-term  and  applies  this  term  to  the  argument  constructors  and  the  result  of 
applying  the  typerec  to  these  constructors: 

ll[typerec(unit;  ey;  ex',  C-^)]  ' — £^[ey] 

jSCtyperec(x  u;  ey;  e^;  e_,)]  i — ^  E\ex[T^\  w][7f2  u] 

(typerec(7fi  u;  Cy;  Cxi  e_^)) 
(typerec(7f2  u;  Cy;  ex',  e^))] 
il[typerec(-b- w;  ey;  ex',  e_^)]  i — £^[e^[7fi  M][7f2  u] 

(typerec(7fi  w,  ey;  ex;  e_)) 

(typerec(7f2  u\  ey;  ex;  e^))] 

The  static  semantics  are  changed  so  that  TypeRec  constructors  are  considered  equivalent 
to  their  “unrolled”  counterparts,  and  the  following  term  formation  rule  is  added  for  typerec 
expressions: 

A  h  r  ;  type  A  h  Vt  :  II. ct  type 
r  1-A  ey  :  (T(unit) 

r  1“A  e_+  ;  Vti  :  fI.Vt2  •  <^(“^(11512)) 

r  hA  ex  :  Vfi  :  <7(12)  (^(x(ti,t2)) 

r  1-A  typerec(r;  ey;  e^;  ex)  :  cr(r) 

Note  in  particular  that  r  is  restricted  to  being  of  kind  fl  (i.e.  a  monotype). 
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makestring  :  Mi  :  — >  string 


makestring  =def  V/ 


where 


es 


0.typerec(/;eu;es;ex;e_») 

=  Ax  :  unit.‘'<>’' 

=  Ax:  string. ("  « ^  ^ 

=  Kti  :  VtAt2  :  fJ.A/i  :  /i  ^  string. A/2  :  ^2  ^  string. Ax  :  ti  x  /2- 

("<"  "  (/i  (tti  x))  (/2  (7r2  a;)) "  ">") 

=  Ati  :  J7.A/2  :  fi.A/i  :  — >■  string. A/2  :  <2  ^  string. Ax  :  ti  ^2- 


Figure  2;  Defining  makestring  in 


4  Overloading 


In  this  section  we  show  how  typerec  can  be  used  to  implement  various  features  that  are  gen¬ 
erally  classified  as  overloading.  A  prime  example  is  Standard  ML’s  polymorphic  equality 
(poly-eq)  that  takes  two  (non-functional)  objects  of  the  same  type  and  returns  an  indication 
as  to  whether  they  are  equal.  Another  example  is  a  print  operation  that  prints  a  represen¬ 
tation  of  an  arbitrary  value.  These  operations  can  be  easily  implemented  by  A^^  -f-typerec, 
and  can  thus  be  exported  to  Mini-ML.  However,  unlike  true  overloading,  the  operations 
must  be  defined  at  all  types. 

Overloaded  operations  are  usually  implemented  by  tagging  values  with  constructor  infor¬ 
mation.  For  example.  Standard  ML  of  New  Jersey  (SML/NJ)  tags  a// values  with  enough 
information  to  support  polymorphic  equality[l].  Our  approach  does  not  tag  values  with 
constructors.  Instead,  we  pass  constructors  only  to  polymorphic  operations  and  keep  the 
computations  on  constructors  separate  from  the  computations  on  values. 

As  an  example,  consider  adding  the  primitive  type  string  to  A^^^  along  with  string  literals 
(e.g.  "foo")  and  an  infix  concatenation  operator  (").  Figure  2  shows  how  a  “makestring” 
function  can  be  coded  using  typerec.  This  function  takes  a  type  and  computes  a  function 
that,  when  given  a  value  of  that  type,  returns  a  string  representation  of  the  value.  The 
interesting  case  is  the  sub-expression  e^,  that,  when  applied  to  two  types  Tj  and  T2,  and 
given  functions  for  converting  values  of  these  types  to  strings,  produces  a  function  that 
takes  a  product  of  these  two  types  and  converts  it  to  a  string.  For  example,  the  expression: 

makestring[string  X  unit]  ("foo",()) 

evaluates  to  the  string  ''< ‘foo’ Note  that  it  is  trivial  to  export  the  makestring 
function  to  Mini-ML  as  a  constant  with  type  Vt.t  — >  string. 

As  is  obvious  from  the  definition  of  makestring,  typerec  expressions  quickly  become  unwieldy, 
so  we  adopt  a  pattern  matching,  recursive  style  in  subsequent  definitions.  As  another 
example  of  using  typerec  to  provide  an  overloaded  operation,  consider  computing  the  size 
of  a  value  in  machine-words  of  memory.  This  is  used  in  languages  such  as  C  to  allocate 
memory,  copy  objects,  etc.  The  sizeof  operation  can  easily  be  expressed  as  an  overloaded 
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function  using  typerec; 


0 
1 

sizeof[ri]  +  sizeof[r2] 

2 

Our  approach  is  similar  to  the  ^^method  passing”  approach  suggested  by  Wadler  and  Blott  as 
an  implementation  technique  for  Haskell  overloading [15].  In  the  method  passing  approach, 
dictionaries  of  methods  (i.e.  functions)  are  passed  as  “hidden”  arguments  to  overloaded 
functions.  The  overloaded  functions  simply  select  and  invoke  the  appropriate  method  from 
the  dictionary.  However,  Augustsson  notes  that  method  passing  is  difficult  to  compile  ef¬ 
ficiently  due  to  the  use  of  higher-order  functions[3].  In  contrast,  our  approach  passes  type 
constructors  which  are  simply  data  structures  as  far  as  a  compiler  is  concerned.  Conse¬ 
quently,  our  approach  may  not  suffer  from  the  same  optimization  difficulties  as  method 
passing.  We  further  highlight  the  differences  between  method  passing  and  our  approach  in 
the  context  of  compiling  polymorphism  in  Section  6.3. 


sizeof[unit]  = 
sizeof[int]  = 
sizeof[x(ri,r2)]  = 
sizeof[A(ri,r2)]  = 


5  Polymorphism  and  Canonical  Representations 

Consider  adding  an  operation  view  to  Mini-ML  along  with  the  following  typing  rule; 

r  Ka  e  :  r  r  =  r' 
r  l-A  view  e  5S  t'  :  t' 

The  rule  allows  us  to  view  e  as  if  it  has  type  r'  as  long  as  we  can  prove  that  e  has  type 
r  and  r'  is  equivalent  to  r.  Figure  3  gives  one  definition  of  equivalence  that  is  generated 
by  considering  tuple  types  equivalent  up  to  associativity.  This  situation  arises  in  languages 
such  as  C  where  structs  (records)  are  represented  in  a  “flattened”,  canonical  form.  Viewing 
a  struct  is  more  efficient  than  constructing  a  copy  of  the  struct  with  the  desired  associativity. 
Furthermore,  viewing  preserves  sharing  of  the  mutable  components  while  copying  does  not, 
because  we  can  view  through  refs. 

In  an  abstract  sense,  view  allows  us  to  observe  that  two  types  are  represented  by  the  same 
canonical  form.  However,  maintaining  a  canonical  form  such  as  C  s  flattened  structs  is 
difficult  in  the  presence  of  polymorphism.  As  each  value  is  created,  we  must  insure  that  the 
value  is  in  the  canonical  form.  But  we  cannot  determine  “the  ^  canonical  form  if  the  object 
is  polymorphic. 

For  example,  consider  the  equivalence  relation  defined  in  Figure  3  and  suppose  we  choose 
right-associated  tuples  as  the  canonical  representation  of  tuple  types.  We  cannot  determine 
whether  the  type  t  X  unit  is  in  canonical  form  or  not,  because  t  could  be  instantiated  to 
unit,  in  which  case  the  tuple  is  canonical,  or  t  could  be  instantiated  to  unit  X  unit,  in  which 
case  the  type  is  not  canonical.  In  this  section,  we  show  how  this  canonical  form  can  be 
maintained  by  using  non-parametric  primitive  operations  in  conjunction  with  typerec.  We 
do  not  use  a  “truly  flattened”  representation  of  tuples  as  do  C  implementations,  because 
A-^-^only  supports  binary  tuples.  However,  in  Section  7  we  discuss  adding  n-tuples  to 
to  support  such  a  representation. 
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Tl  =  T2 


T2  =  Ta 


T  =  T 


r\  =  Ta 


Tl  =  t[  T2  =  T2 
Tl  X  r2  =  t[  X  T2 


Tl  =  t{  T2  =  T;^ 
Ti-^T2  =  t{->T2 


T  =  T 


T  ref  =  r'  ref 


Tl  X  {t2  X  Ta)  H  (ri  X  T2)  X  ra 


Figure  3:  Associativity  Equivalence  of  Tuples 
We  start  by  giving  a  translation  on  types, 


\tl 

=  t 

|unit|b 

=  unit 

k  '■eflb 

=  ref(|T|b) 

ki^'r2|b 

=  ^(kilb, 

k2|b) 

ki  X  T2I1, 

=  kilb 

k2lb 

where  cr^  is  defined  using  the  type  constructor  TypeRec  to  “flatten”  tuple  types  into  a 
right-associated  form: 

<7^  ‘  fi.TypeRec(/i ;  5 

Uu  =  x(unit,/2) 

where  :  fi.x(/a,^6) 

\ta,th,taA  *  *  X  (  A  (^  ,  4) ,  ^2) 

Recall  that  the  TypeRec  constructor  is  equivalent  to  its  unrolled  counterpart  and  the  un¬ 
rolling  is  guaranteed  to  terminate  because  the  type  argument  is  constrained  to  be  a  mono¬ 
type  (kind  fi). 

The  translation  on  terms  must  be  modified  so  that  tuples  are  created  in  their  canonical  form 
and  projections  extract  the  appropriate  components  according  to  the  source  types.  In  the 
translation  rules  below,  we  have  encapsulated  these  operations  into  three  non-parametric 
functions:  pair^,  proj^  and  proj^. 

r  t-A  €1  :  Tl  |ei| 

_ T  \-A  e2  :  T2  \^2\ _ 

r  l-A  (61,62)  :  Tl  X  T2  pair‘’[|Ti|i,][|T2|i,]  |ei|  |e2| 

r  Ha  6  :  Tl  X  T2  =>b  |e| _ 

r  l-A  TTi  e  :  Ti  =>b  proj-[|Ti|b][|T2|b]  \e\ 

The  definitions  of  pair*"  and  proj;  are: 

pair*’  :  Vti,t2  :  t2  —>■  (o'*’  ti  ^2) 

pair*’[unit][T2]  =  Xx  :  unit. Ay  :  T2.{x,y) 
pair‘’[A(Ta,T6)][T2]  =  Xx  : -^{Ta,n),Xy  :  T2.{x,y) 

pair*’[x(To,T(,)][T2]  =  Xx  :  x(Ta,T6),  Ay  :  T2.(7ri  a:,pair*’[T6][T2]  (^2  x)  y) 
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proJi  :  Vii,i2  :  ^-{cr^  h  t2)  — ^ 

proji[unit][r2]  =  Aa;  :  x(unit,r2).7ri  a; 
proji[-4(ra,r6)][r2]  =  Aa;  :  x(-^(ra,r6),r2).7ri  a; 
proj^[x(r„,r6)][r2]  =  Aa:  :  x(x(ra,r6),r2).(7ria;,proji[r6][r2](7r2a;)) 

proj2  :  Vfi,/2  :  h)  h 

proj2[unit][r2]  =  Aa;  :  x(unit,r2).7r2  a; 
proil[-^{Ta,n)][T2]  =  Xx  :  X{-^{Ta,Tb),T2).'K2X 
proj2[x(ra,r6)][r2]  =  Aa;  :  x(x(ra,rt),r2).proj^[r6][r2]  (7r2  a;) 

We  have  used  the  pattern-matching  style  definitions  for  readability,  but  these  can  be  coded 
using  typerec. 

The  interesting  case  in  each  of  the  definitions  is  the  product  case.  For  the  pair^  function^the 
product  case  causes  the  pair  x  to  be  flattened  onto  y  by  projecting  oflF  the  first  component 
of  X  and  pairing  it  with  the  flattening  of  the  rest  of  x  with  y.  For  the  proj^  function,  the 
product  case  projects  the  component  using  tti  and  the  u  component  using  proji[r6][r2] 
and  tuples  them  to  produce  the  result.  For  the  proj^  function,  the  product  case  removes 
the  Ta  component  using  7r2  and  removes  the  n  component  using  proj2[rt][r2]. 

Whenever  pair'’  or  proj^  are  used  at  monomorphic  types,  the  type-applications  and  typerec 
occurrences  can  be  ehminated,  resulting  in  a  series  of  primitive  pairing  and/or  projection 
operations. 


6  Compiling  Polymorphism 

In  monomorphic  languages  such  as  C,  types  are  used  to  describe  the  size  and  shape  of  a 
data  structure’s  representation.  Operations  such  as  pairing  and  projection  are  compiled  to 
primitive  operations  that  differ  according  to  the  types.  For  example,  assuming  fioats  are 
two  words  and  ints  are  one  word,  a  pairing  operation  on  fioats  (pairfioat, float)  allocate 

twice  as  much  memory  as  a  pairing  operation  on  ints  (pairjnt  jnt).  Since  aU  types  can  be 
determined  statically  in  a  monomorphic  language,  the  compiler  can  choose  the  appropriate 
primitive  operation  (e.g.  pairjn^  versus  pairfiQgt, float)  compile  time. 

In  a  polymorphic  language,  however,  it  becomes  difficult  to  choose  “the”  primitive  operation 
at  compile  time,  because  the  type  might  vary  at  runtime  through  polymorphic  instantia¬ 
tion.  This  issue  is  entirely  glossed  over  by  the  standard  translation  of  Section  2.3.  In  this 
section,  we  discuss  three  techniques  for  solving  this  problem.  The  first  technique,  used  by 
the  SML/NJ  0.93  system,  abandons  the  idea  that  types  describe  the  shape  of  objects  and 
converts  objects  to  a  universal  representation  so  that  a  single  primitive  operation  suffices 
for  all  cases  and  can  always  be  selected  at  compile  time.  However,  this  approach  introduces 
indirection  in  the  data  structures  which  can  be  expensive  in  both  space  and  time.  The 
second  approach,  described  by  Leroy  and  used  in  the  Gallium  compiler,  compiles  monomor¬ 
phic  code  using  the  natural  representation  and,  roughly  speaking,  polymorphic  code  using 
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the  universal  representation.  Coercions  are  introduced  to  convert  values  to  and  from  the 
universal  representation  as  necessary,  yet  the  coercions  and  all  primitive  operations  are 
selected  at  compile  time.  However,  Leroy’s  approach  does  not  extend  directly  to  mutable 
objects  and  does  not  work  well  with  large  objects.  The  third  approach  uses  non-parametric 
primitive  operations  to  avoid  ever  having  to  introduce  indirection  in  data  structures  at  the 
cost  of  selecting  some  primitive  operations  at  run  time.  Furthermore,  the  approach  extends 
directly  to  mutable  objects.  It  is  particularly  illuminating  to  see  all  three  approaches  in  our 
type-directed  translation  framework. 

6.1  The  Boxing  Approach 

In  SML/NJ  (versions  0.93  and  earlier)[2],  all  objects  are  represented  in  a  unmersa/ fashion 
so  that  primitive  operations  may  be  selected  at  compile  time.  This  is  accomplished  by 
boxing  values  that  is,  placing  objects  larger  than  size  one  in  memory  and  using  a  pointer 
to  the  object  as  its  representation. 

We  can  cast  the  boxing  strategy  into  our  type-directed  framework  as  follows.  We  add  to  the 

set  of  monotypes,  box(r),  representing  boxed  values  and  we  assume  two  new  families 

of  operations,  box,-  and  unbox,-  that  convert  objects  to  and  from  the  boxed  representation 

at  the  appropriate  type.  We  further  assume  that  primitive  operations  such  as  pairing 

and  projection  work  uniformly  on  boxed  types.  So,  for  example,  pair,  •  .  ,  •  .  = 

^  box(int),box(int) 

P^"'box(float),box(float)  P^'''box,box  primitive  pairing  operation  on 

boxed  values,  regardless  of  the  type. 

The  type  translation  for  the  boxing  strategy  is  defined  as  \t\b  using  an  auxiliary  definition, 

Iklis: 

II^IIb  = 

||unit||B  =  unit 
lkiXr2jji3  =  x(ki|B,k2|s) 
lkl^T2||i5  =  -^(|ri|B,|r2|B) 

\t\b  =  box  ||r||B 

|Vfi,...,t„.r|B  =  Vfi  :  Q, . . .  :  fi.|r|s 

The  full  term  translation  is  given  in  Appendix  C,  but  we  note  here  that  introduction  rules 
box  their  results  while  elimination  rules  unbox  their  arguments.  For  example,  the  pair  and 
projection  rules  are: 

_ F  Fa  ei  :  n  =^b  |ei|  F  Fa  £2  :  T2  |e2| _ 

F  Fa  (61,62)  :  ri  X  r2  ^b  boXbox>;box(pa'''box,box(|eiMe2|)) 

_ F  Fa  e  :  Ti  X  r2  |e| _  .  _  ^  2) 

F  Fa  TTie  :  n  ^b  proj,- boxxbox(unboxbox(|e|)) 

The  identifier  rule  must  use  the  auxiliary  type  translation,  ||t||b,  in  instantiation  since  we 
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have  already  required  that  t  be  translated  to  box(t): 

T{x)  =  'iti,...,tn.T 
A  I-  ri  type  ...  A  h  type 

r  hA  X  :  [Ti/ti,...,Tn/tn]T  *[1 1^1  |s]  •  •  •  [I kn| |b] 

It  is  straightforward  to  show  that  the  boxing  translation  like  the  standard  translation  pre¬ 
serves  its  type  translation.  The  key  lemma  one  must  prove  is  that  ||/)||s(|r|B)  =  |p(t)|b, 
where  p  is  the  substitution: 

p  {/;|^  \-^  Ti, .  .  .  ,  ^ 

and  WpWb  is  the  substitution  that  maps  t  to  ||p(t)llB.  Once  type  correctness  of  the  trans¬ 
lation  is  established,  it  is  easy  to  see  that  all  primitive  operations  have  been  effectively 
selected  at  compile  time  by  the  translation,  since  all  values  are  boxed  and  there  is  only  one 
primitive  operation  for  boxed  values,  regardless  of  the  type. 


6.2  Leroy’s  Approach 

The  boxing  compilation  strategy  produces  excessive  indirection  which  can  cost  substantially 
in  both  space  and  time.  Leroy  proposed  an  alternative  strategy  that  only  boxes  values  that 
are  given  the  type  t  (a  type  variable.) [7].  Consequently,  only  polymorphic  code  pays  the 
price  of  indirection. 

We  can  cast  Leroy’s  compilation  strategy  into  our  type-directed  translation  framework  as 
follows.  We  define  a  type  translation  from  Mini-ML  to  (extended  with  box)  that  only 
boxes  polymorphic  objects: 

box  t 
unit 

x(lrili„|T2|L) 

[iti,  .  .  .  ,tn.T\l,  =  Vtl  :  fl,  .  .  .  ,  tn  • 

The  term  translation  is  similar  to  the  standard  translation  of  Section  2.3.  In  particular,  no 
boxing  is  introduced  by  the  value  creation  rules.  However,  a  type  mismatch  arises  in  the 
identifier  translation  rule,  because  a  polymorphic  object  is  compiled  as  if  t  is  boxed,  but 
the  use  expects  it  to  be  unboxed.  That  is,  if  p  is  the  substitution  used  in  the  instantiation 
rule  to  map  type  variables  to  types,  then  \p\l{\t\l)  7^  \p{r)\L-  Leroy  suggests  applying  a 
coercion,  Sp  to  the  polymorphic  object  at  its  uses  to  convert  the  object  to  the  appropriate 
type,  based  on  p.  Thus,  the  translation  rule  for  identifiers,  making  p  explicit  becomes: 

r(x)  =  Vti,...,t„.r 

P  —  {^1  ^  Ti, .  .  .  ,/n  ■^n} 

Ahp(ti)  type  ...  A\- p{tn)  type _ 

rf-A  x  :  [p{tl)/ti,...,p{tn)/tn]r  S pix-,T)[\p{ti)\L]  ■  ■ -MtnM 

The  definition  of  Sp  is  given  below  along  with  the  dual  coercion,  Gp,  that  is  necessary  for 
coercing  functions.  S  stands  for  ^^specialization”  and  G  for  *  generalization  .  Technically, 


\t\L  = 
|unit|L  = 
In  X  r2jL  = 
In^nlL  = 
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we  should  use  the  type-specific  primops  such  as  pair^^  proj,'  .rj,T2  the  definitions 

instead  of  the  generic  primops  such  as  (•,•)  and  tt,-. 


Sp{e;t) 
Sp{e-,t) 
^^(eiunit) 
Sp{e;Ti  X  T2) 
Spie-,Ti-^T2) 


unbox|p(<)l^(e)  {t  e  Dom{p)) 

e  {t  ^  Dom(p)) 

e 

let  x  =  e  in  (^^(Tri  x]  ri),5p(7r2  x;  T2)) 
let  /  =  ein  Aa;  :  |ri|£.5p(/(G'p(a:;r2));ri) 


Gp{e\t) 
Gp{e;t) 
Gp(e;  unit) 
Gp(e;ri  x  T2) 

Gp(e;ri->r2) 


hox|p|L(|<li,)(^)  (t  €  Dom{p)) 

e  (t  ^  Dom{p)) 

e 

let  x  =  e\n{Gp{TTix;Ti),Gp{iT2x;T2)) 
let  /  =  einAa;  :  |ri|z,.Gp(/(6'p(a;;r2));ri) 


In  order  to  prove  translation  type  preservation,  we  need  to  show  that  Sp  is  a  function  of 
type  \p\l{\t\l)  ->■  \p{t)\l-  Similarly,  we  need  to  show  that  Gp  has  type  \p{t)\l  -s-  |/>|l(|t|£,). 

As  with  the  boxing  translation,  Leroy’s  coercion  translation  has  effectively  selected  the  prim¬ 
itive  operations  at  compile  time.  Furthermore,  there  appears  to  be  less  boxing/unboxing  of 
values.  In  particular,  boxing/unboxing  only  occurs  if  polymorphism  is  used. 


6.3  Our  Approach 

Unfortunately,  Leroy’s  approach  does  not  directly  extend  to  mutable  data  structures  such  as 
refs  or  arrays,  and  is  impractical  for  “large”  objects  such  as  vectors  and  lists.  The  problem 
is  that  Sp  and  Gp  essentially  copy  an  object,  changing  some  of  the  components  to/from  the 
boxed  state.  Copying  is  expensive  for  large  objects  and  is  incorrect  for  mutable  objects. 
If  we  add  ref  to  Mini-ML,  then  we  would  like  to  leave  the  contents  of  ref  cells  unboxed  in 
the  translation  to  but  we  cannot  extend  the  Sp  and  Gp  conversions  directly  to  support 
this.  A  first  attempt  at  extending  Sp  to  refs  is: 

^^(eirref)  =  ref(5p(!e;  r)) 

but  this  does  not  preserve  sharing  of  refs.  A  second  attempt  at  extending  Sp  is: 

Sp{e\ T  ref)  =  let  a:  =  e 
in 

X  :=  5p(!a;;r) 
end 

but  this  is  unsound  since  the  contents  of  x  must  simultaneously  have  type  \p{t)\i,  and 
IpIl(I^Il))  which  are  not  necessarily  the  same. 

Leroy  suggests  two  ways  to  fix  this  shortcoming.  The  first  technique  treats  a  ref  cell  (or 
large  object)  as  if  its  contents  were  polymorphic  and  thus  the  contents  are  boxed.  In  fact, 
as  Leroy  points  out,  the  contents  must  be  recursively  boxed.  To  see  the  problem,  note  that 
a  ref  containing  a  tuple  of  must  be  “viewable”  as  not  only  a  tref,  but  also  a  (U  x  ^2)  ref. 
A  consequence  of  this  is  that  the  S  and  G  coercions  must  be  changed  at  type  variables 
to  recursively  unbox/box  values.  Obviously,  this  approach  can  be  quite  expensive.  As  an 
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example,  a  polymorphic  array  instantiated  to  be  a  float  array  must  box  all  of  the  floats. 
If  the  array  is  instantiated  to  be  an  array  of  complex  numbers  (i.e.,  pairs  of  floating  point 
numbers),  the  tuples  and  their  components  must  be  boxed. 

The  second  technique,  used  by  the  Gallium  compiler,  associates  methods  (i.e.,  functions) 
with  a  ref/array  to  read  and  write  components  of  the  ref/array.  In  this  fashion.  Gallium  is 
able  to  keep  the  components  of  the  mutable  object  unboxed  since  the  S  and  G  conversions 
can  be  applied  to  the  methods  instead  of  the  data.  The  method  passing  approach  was  also 
proposed  by  Wadler  and  Blott  as  an  implementation  technique  for  Haskell  overloading[15]. 

An  alternative  approach  to  method  passing  that  we  propose,  is  to  pass  type  information  to 
the  read  and  write  operations  on  arrays  and  let  them  compute  the  appropriate  primitive, 
monomorphic  read/write  operation,  possibly  at  runtime.  This  amounts  to  making  read 
and  write  non-parametric  polymorphic  operations.  Furthermore,  we  note  that  other  data 
structures,  such  as  tuples,  may  always  be  unboxed  by  making  pairing  and  projection  non- 
parametric  polymorphic  operations.  In  fact,  boxing  can  be  eliminated  entirely  from  data 
structures^  simply  by  translating  aU  polymorphic  primitive  operations  to  non-parametric 
polymorphic  functions  that  compute  the  appropriate  monomorphic  operation  based  on  the 
type.  Of  course,  if  the  operations  are  applied  to  monomorphic  types,  then  the  type  compu¬ 
tations  may  be  eUminated  at  compile  time.  Thus,  Uke  the  method  passing  approach,  only 
polymorphic  code  pays  the  price  of  computing  a  primitive  operation  at  compile  time. 

Here  we  sketch  briefly  and  at  a  high-level  how  the  non-parametric  approach  is  formalized  in 
our  framework,  so  that  boxing  may  be  eliminated  from  tuples.  The  same  techniques  can  be 
applied  to  function  application  (to  unbox  arguments  and  place  them  in  registers),  refs  and 
arrays,  and  other  data  structures.  We  assume  that  the  following  non-parametric  operators 
are  added  to  ,  as  we  added  typerec: 


pair 

Vii,t2 

O./i 

t2  — 

(tl 

proji 

Vtl,t2 

0.(ti 

X  ^2) 

Pl'0j2 

Vtl,t2 

D.(/i 

X  t2)  - 

t2 

These  operations  are  essentially  functions  that  compute  the  appropriate  primitive  operation 
according  to  their  type  arguments,  so  we  add  the  following  corresponding  reduction  rules: 

i;[pair[ri][r2]]  i — ^  Aa;i  :  ti.\x2  :  r2.pair^j_.,2  xi  X2 
-E[proji[ri][r2]]  Aa;  :  (n  X  r2).proji^^j_^2  a; 

-E[proj2[rij[r2i]  ^  Aa;  :  (n  x  r2).proj2,^j,^2  ^ 

It  is  reasonable  to  assume  such  operations  because  these  functions  are  defined  by  a  compiler 
for  a  monomorphic  language. 

The  translation  is  straightforward:  we  simply  map  (ei  :  ri,e2  :  r2)  to  pair[|ri|][|r2l]  |ei|  le2| 
and  similarly  for  projection.  However,  we  can  speciahze  the  translation  in  order  to  guarantee 
that  the  appropriate  primitive  operations  are  chosen  by  the  translation  for  monomorphic 
code.  This  is  done  by  introducing  two  translation  rules  for  each  operation:  one  for  the 
monomorphic  case  that  performs  the  above  reductions  at  compile  time  and  one  for  the 

is  worth  noting  that  boxing  cannot  be  directly  eliminated  from  closures  based  on  types,  because  the 
type  does  not  teU  us  the  size  of  the  code  nor  the  types  of  the  free  variables. 
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general  case  where  the  reduction  is  delayed,  possibly  until  run  time. 


r  Ha  ei  :  ti  =>o  kil  T  I-a  62  :  T2  =>o  1^21 
_ FTV{n)  =  FTV{t2)  =  0 _ 

r  l-A  (61,62)  :  ri  X  r2  :^o  pairn.rj  kil  kzl 


r  f-A  61  :  Ti  =j>o  |ei|  r  l-A  62  :  r2  =>o  I62I 

FTV{ti)  0  FTV{t2)  7^  0 

r  l-A  (61,62)  :tiXT2  pair[T-i][r2]  |6i|  |62| 


r  l-A  6  :  Ti  X  r2  =4>o  \e\ 
FTVjn)  =  FTViT2)  =  0 

r  l-A  TTi  6  :  Ti  =^o  Proji.Ti  ,T2  |c| 


r  l-A  6  :  Ti  X  r2  =>o  |e| 

FTVjn)  ^  0  FrF(r2)  7^  0 
r  l-A  TT,-  6  :  Ti  =>o  proji[ri][r2]  |e| 

It  is  worth  noting  that  as  soon  as  a  type  becomes  closed,  these  reductions  can  be  made. 
Consequently,  if  the  non-parametric  approach  is  used  to  implement  polymorphism  at  the 
module  level,  these  type  reductions  can  occur  when  a  functor  is  applied  to  a  structure 
argument. 

The  boxing  approach  and  Leroy’s  approach  have  one  advantage  over  message-passing  and 
our  approach:  no  restriction  is  needed  on  polymorphic  generalization  (see  Section  2.3), 
so  these  techniques  work  directly  for  Standard  ML.  But,  as  mentioned  earlier,  Wright 
has  found  that  the  value  restriction  is  not  a  problem  in  practice.  Furthermore,  the  non- 
parametric  approach  has  an  important  advantage  over  boxing  and  Leroy’s  technique  for 
compiling  polymorphism:  Since  boxing  need  never  be  introduced  (nor  prohibited)  in  the 
representation  of  data  structures,  interfacing  to  an  external  entity  such  as  a  C  procedure, 
or  the  operating  system,  or  a  device  becomes  much  simpler  and  more  efficient  since  the 
representation  demanded  by  the  external  entity  can  be  met  directly.  This  is  true,  of  course, 
only  if  tags  for  other  purposes  such  as  garbage  collection  or  polymorphic  equality  can  be 
eliminated  from  the  representation.  Fortunately,  as  we  have  shown  earlier,  overloaded 
operations  such  as  polymorphic  equality  can  be  implemented  as  a  non-parametric  operation, 
so  values  do  not  need  to  be  tagged  for  this  purpose.  Furthermore,  Tolmach  has  recently 
shown  that  by  translating  ML  into  a  second-order  language  like  ,  copying  garbage 
collection  can  also  be  implemented  without  the  need  to  tag  objects[14]. 

Of  course,  method  passing  can  be  used  to  eliminate  boxing  as  well,  since  method  passing  and 
our  approach  appear  to  be  duals  of  each  other.  However,  with  method  passing,  a  method 
for  each  primitive  operation  (including  pairing,  reading/writing  from  a  ref,  etc.)  must  be 
eagerly  constructed  when  a  polymorphic  function  is  instantiated  because  we  cannot  tell  how 
the  object  we  pass  to  the  function  will  be  used.  Augustsson  reports  that  computing  all  of 
these  methods  is  a  source  of  inefficiency  in  most  implementations  of  Haskell  type  classes[3]. 
In  contrast,  for  a  non-parametric  operation,  “methods”  are  constructed  lazily  at  the  point 
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where  they  are  used  while  a  single  type  is  constructed  eagerly.  Which  approach  leads  to 
superior  performance  is  application  and  implementation  dependent.  Fortunately,  the  two 
approaches  are  not  incompatible:  if  a  primitive  operation  is  found  to  be  frequently  used,  for 
instance  computing  the  size  of  an  object,  then  the  method  passing  approach  can  be  used  to 
implement  the  operation.  Other  operations  can  be  implemented  using  non-parametricity, 
with  the  expectation  that  they  will  be  invoked  at  most  once. 


7  Conclusions  and  Future  Work 

We  have  demonstrated  that  by  translating  ML-like  languages  into  a  second-order,  explicitly 
typed  language  extended  with  the  ability  to  define  non-parametric  operations,  we  can  ad¬ 
dress  and  solve  a  variety  of  hard  language  implementation  problems,  including  overloading 
and  unboxed  representations  in  the  presence  of  polymorphism.  Our  approach  is  to  define 
a  type-directed  translation  from  the  source  language  to  the  target  language.  The  target 
languages  we  have  used  are  based  on  ,  a  stratified  language  in  which  monotypes  can 
be  thought  of  as  being  inductively  defined.  Consequently,  we  are  able  to  extend  with 
induction  elimination  forms  (e.g.  typerec)  to  support  the  definition  of  non-parametric  op¬ 
erations,  yet  type  checking  for  the  target  language  remains  decidable. 

The  problems  we  have  concentrated  on  are  essentially  representation  issues:  We  are  con¬ 
cerned  with  providing  the  programmer  and/or  the  implementor  of  a  polymorphic  language 
with  maximal  control  over  representations  of  data  structures.  In  particular,  we  have  shown 
how  unnecessary  indirection  (boxing)  may  be  eliminated  even  in  the  presence  of  polymor¬ 
phism  and  we  have  shown  that  it  is  not  necessary  to  tag  objects  to  support  language 
features  such  as  overloading.  Others,  such  as  Tolmach  and  Ohori,  have  backed  this  claim 
by  demonstrating  that  even  more  language  features,  notably  copying  garbage  collection  and 
polymorphic  field  selection,  can  be  implemented  using  this  same  general  technique. 

We  still  have  many  difficult  open  problems  to  address:  First,  we  expect  that  A^^may 
be  extended  to  work  with  n-tuples  instead  of  just  binary  tuples,  but  the  details  have  not 
been  worked  out.  The  basic  idea  is  to  add  O  list  to  the  kinds  and  consider  “n-tuple”  as  a 
constructor  of  kind  O  list  ^  O.  Then,  an  induction  elimination  form  (fold)  on  these  lists 
may  be  added  as  a  term.  N-tuples  are  necessary  to  implement  truly  fiattened  representations 
of  tuples  efficiently.  Second,  we  see  no  way  to  provide  an  induction  elimination  form  for 
general  recursive  types  without  losing  decidabifity  of  type  checking.  However,  inductively 
defined  recursive  types,  such  as  lists  and  trees,  can  be  effectively  de-structured  by  a  finite 
unrolling,  so  we  expect  that  we  can  add  a  simple,  but  effective  facility  for  such  types.  Third, 
there  are  obvious  connections  between  views  and  subsumption  and  we  hope  to  explore  this 
in  order  to  support  an  efficient  implementation  of,  for  instance,  record  subsumption  in 
the  style  of  Ohori.  Finally,  we  are  in  the  process  of  building  a  prototype  compiler  that 
translates  SML/NJ  source  to  an  intermediate  language  based  on  the  concepts  of  A^^and 
a  back-end  that  supports  unboxed,  tagless  representations.  We  hope  to  use  this  prototype 
empirically  to  explore  tradeoffs  in  representation  techniques  such  as  method  passing  versus 
non-parametric  operations. 
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A  (with  typerec)  Static  Semantics 

A.l  Constructor  Formation 


Ah  t:k 


A{t)  =  k 


A  h  unit  : 


Al-x:f]xfi->f2 


A  h  :  A:i  Ah  U2  :  k2 
A  h  (ui, U2)  :  A:i  X  k2 


A  h  u  :  ki  X  k2 

Ah  ii  u  •.  ki 


(i=  1,2) 


A,  /  :  h  t/  :  /:2 
A  h  A /  :  Ari.tt  :  /:i  k2 


A  h  ui  :  ki  ^  k2  A  U2  :  ki 
A  h  ^2  ’  ^2 


Ah  u  :  rt  Al-^/u-^^ 
Ahwx 

A  h  TypeRec(w ;  Uu]  Ux  ;  u^)  : 


A. 2  Type  Formation 


A  \-  u  :  Q 

A  h  unit  type  A  I-  T{u)  type 


A  h  <7i  type  A  h  <J2  type 
A  h  (7i  X  (J2  type 


A  h  (Ji  type  A  H  (J2  type 
A  H  cTj  — <72  type 

A. 3  Term  Formation 


Aha  type  r(a:)  =  a 
T  X  :  a 


A,t  :  k  \-  a  type 
A  h  V/  :  k.a  type 


r  Ha  0  :  unit 
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r  Ha  :  ai  T  Ha  ^2  :  o'2 

r  l-A  (61,62)  :  0-1  X  0-2 


r  Ha  6  :  0-1  X  (72 

— — -  (*=1,2) 

i  Ha  TTi  e  :  ai 


r  h A,t:fc  6  :  (7 

r  Ha  Ai  :  fc  .e  :  Vi  :  k.a 


(i  ^  £)om(A)) 


r,a:i  :  ((7i  (72), ^2  :  (7i  Ha  6  :  (72 

r  Ha  fixa;i(a;2  :  (7i).e  :  (7i  (72 


(a;i,a;2  ^  Dom(r)) 


r  Ha  6  :  Vi  :  k.a 

r  Ha  6[ii]  :  ['ti/i](7 


r  Ha  61  :  (7i  -»  (72  r  Ha  62  :  ai 
r  Ha  61  62  :  (72 


r  Ha  6  :  (7i  r  Ha  CTI  =  (72  type 
r  Ha  6  :  (72 


A  H  r  :  O  type  A  H  Vi  :  0.(7  type 

r  Ha  6u  :  (7(unit) 

r  Ha  6_>  :  Vii  :  O.Vi2  :  Q,.a{ti)  — >  (7(i2)  — ^  i7(— >(ii,i2)) 
r  Ha  6x  :  Vii  :  0-Vi2  :  0-(7(ii)  <7(i2)  (7(x(ii,i2)) 

r  Ha  typerec(r;  eu;  6_;  e^)  :  a{T) 

A. 4  Constructor  Equivalence 

A  H  wi  :  A:i  A  H  U2  :  ^2 

—  ^  '  j.  ^  ^  J 

A  H  7fi  (wi,  **2)  =  Ui  :  ki 


A  H  li :  fci  X  A;2 
A  H  (tti  u,  772  u)  =  u  :k\Xk'i 

A\-  ui  :  ki  A,t  :  ki  U2  k2 
A  H  (Ai  :  ki.U2)  Ui  =  [ui/i]ti2  :  ^2 


Ah-  u  :  ki  k2 
A  H  Ai  ;  ki.{u  i)  =  u  :  fci  ^2 


(i  ^  Dom{A)) 
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A  h  TypeRec(unit;  Uu;  u^)  :  ft 
A  h  TypeRec(unit;  Uu;  u^',  u^)  =  Uy  :  Q 


_ A  h  TypeRec(x(Mi,^2);  ^u;  u^)  :  Q 

A  h  TypeRec(x(Mi,«2);  «□;  u^]  w^)  =  Ux(TypeRec(«i;  Uu;  u^;  w^))(TypeRec('ii2;  Wu;  Ux', 

_ A  h  TypeRec(A(Mi,M2);  Wu;  Ux;  u^)  :  Q, 

A  h  TypeRec(-4(-i/i,u2);  Wui  Ux',  =  u_(TypeRec(ui;  «u;  Ux;  u-^))(TypeRec(w2;  Wx;  w_)) 

A. 5  Type  Equivalence 

_ A  h  Ti  =  r2  : 

A  h  T(unit)  =  unit  type  A  h  T{ti)  =  T{t2)  type 


A  h  r(x(ri,r2))  =  r(ri)  X  T(r2)  type 


Ahr(A(ri,r2))  =  T(ri)->r(r2)  type 

B  The  Standard  Translation 

W 

|unit| 

\t1  X  T2\ 

\Ti^r2\ 

|Vii, . . .  ,<„.r|  =  Vti  :  J), . . .  ,t„  :  n.|r| 

r(a;)  = 

_ A  h  ri  type  ...  A  h  type _ 

r  X  .  [ti  /ti,  ,  Tn/tn]T  =^5  2^[|7'i|5]...[|r„|5] 


r  l-A  0  :  unit  =>  0 


=  t 
=  unit 

=  x(|ri|,|r2|) 

=  ^(ki|,k2|) 
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r  l-A  ei  :  Ti  =»  |ei|  F  I-a  €2  : 7~2  =»  |e2| 
r  l-A  (61,62)  :TiXT2=^  (l6l|,|62|) 


r  Ka  6  :  Ti  X  r2  |6| 
r  l-A  TTj  e\Ti^  -Ki \e\ 


(*  =  1,2) 


r  l-A  fixa;i(a;2).e  :  ri  ^  r2  =>  fixa;i(a;2  :  |T-i|).|e| 

r  l-A  61  :  ri  ^  r2  =>  |ei| 
r  l-A  62  :  Ti  I62I 
r  l-A  61  62  :  r2  ^  |ei|  |e2| 


r  l-A,ti,..,t„  v.t'  ^  |i;| 
r[a:  H->-  Vii, . . .  ,tn.T']  l-A  6  ;  r  |e| 
r  l-A  let  x  —  v\ne\T=^ 

(Aa;  :  V/i  :  fi, . . .  ,tn  :  f2.|r'|.le|)(Ati  :  fi, . . .  :  0  .|i;|)  (/*•  ^  A) 

C  The  Boxing  Translation 


II^IIb 

||unit||B 

Ikl  X  ^21|b 
\\ti-^T2\\b 

\Ab 

j V/i ^ 


r(a;)  =  V/i,...  ,i„.r 
A  h  Ti  type  ...  A  h  r„  type 
ri-A  a;  :  [n/ti,...  ,r„/t„]r  a;[||ri||B] . . .  [||r„||s] 


=  t 

=  unit 

=  x(|ri|s,lr2|B) 

=  ^(|n|B,|'r2|B) 

=  box  \  \t\\b 

—  V^i  tfi  .  0. 1 t|^ 


r  l-A  0  :  unit  ^B  boXunit  () 
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_ r  l-A  Cl  :  Ti  |ei|  r  Ha  62  :  ^2  =>b  |e2| _ 

r  1“ A  {^1-1^2)  •  ^1  X  T2  B  ^®^boxxbox(P^'^box,box(l^l l>  l^2|)) 


r  1-A  e  :  ri  X  r2  =>b  |e| 
r  l-A  TT.  e  :  r,  =^b  proj;  boxxbox(“"boxbox(|e|)) 


(i  = 


r,a;i  V.(ri  T2),X2  •->  V.ri  Ha  e  :  r2  |e| 
r  1-A  fix3;i(a-2).e  :  n  ^  T2  =^b  boxbox^box^'^ ^1(^2  :  ki|B)-kl 


r  l-A  ei  :  n  ^  T2  =>b  kil 

_ r  1-A  62 :  n  ^B  1^2] _ 

r  1-A  ei  62  :  T2  ^b  (unboxbox-vbox  kil)  1^21 


r  1-A, ii, v.t'  ^B  bl 

r[a:  V<i, . . .  ,/„.r']  Ka  e  :  r  =^B  |e| 

r  Ha  let  X  =  v\ne  :  T  =>B 

(A  a;  -.Mil  :  :  fi.|r'|B.|e|)(A<i  :  fi, . . .  .|v|) 


,2) 

(0:1, X2  ^  r) 


(Zi  ^  A) 
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